1. The Field of the Invention
This invention relates to distribution of software over a network and, more particularly, to novel systems and methods for using directory services data stores as a mechanism for effecting software distribution by nodes at the lowest possible node level in a hierarchy.
2. The Background Art
Distribution of software has become an industry within an industry. Manufacturers of software products must distribute those products to users. Meanwhile, system managers responsible for maintaining synchronization of software versions of licensed software, databases, internal software tools, and the like have no small task.
Software distribution has associated therewith an additional problem. Communication of the need for software must be made. Moreover, authorizations, timing, delivery, and the like, are issues that each user at a node in a network or a broader internetwork must accommodate. Likewise, system managers within organizations, departments, companies, sites at disparate locations, and the like must decide, authorize, distribute, and manage over organizations and wide physical terrain. The "sneaker net" is still in use, by which system managers actually distribute physical (e.g., on floppy disk, CD-ROM, etc.) copies of software. Moreover, many decisions are charted manually, authorization lists are authored and distributed, with feedback by any number of methods.
Directory services have been developed, creating logical entities combined in data stores to represent organizations and entities that physically exist. One such popular directory services system is the Novell Directory Services (NDS) based on the X.500 network services protocol published by the CCIT and Open Systems Interconnection Consortium. A memory device 14 may include volatile random access memory 20, read-only memory 18, non-volatile memory 16/18, or the like. In the example of client/server networks, a distributed directory may span several server nodes in a network. Information on a distributed directory may be created, read, modified, and shared by multiple nodes, such as client nodes or server nodes in networks of various sizes.
A distributed directory typically contains a collection of objects, sometimes referred to as entities or identities, each having associated attributes or properties. For example, an object may represent a person, a particular computer, an organizational structure, a machine in a factory, an item or inventory, or the like. Associated attributes may include names, titles, identifiers, and the like having values recognizable by some software accessing such a distributed directory. Objects in a distributed directory may represent users, software objects or modules, computers, peripheral devices connectable to computers such as printers, data or software resources available to a user or a computer in a library, available files, programs, and the like.
In the directory services system, a structure of a distributed directory may be covered by a set of rules for adding and managing objects, and attributes of objects within a distributed directory.
For example, rules may specify, such as through a dictionary, a standard set of data types, according to which objects may be created. Thus, an object may belong to a class having certain associated attributes. Attributes may be based on a set of standard attribute types, in turn based on certain standard attribute syntax.
An important part of directory services data structures (e.g. objects) is the ability to represent relationships among objects in a distributed directory. A schema typically controls these relationships, specifying a certain hierarchy among object classes. A group of object classes may exist, within which bounds, certain subordinate objects may be formed within a hierarchy. An object that contains another object is referred to as a container object. Container objects are building blocks of a distributed directory. An object incapable of containing another object may not have subordinate objects within an hierarchy. Thus, such an object is a leaf object or a terminal object in a tree (hierarchy) of objects.
A distributed directory may be arranged in a hierarchical structure in the form of a tree, wherein branching points or terminal points (leaves) represent objects, and theater connecting branches represent relationships. The relationships are typically contained in the binding between different objects or different object types.
A distributed directory may be organized in partitions, each made up of some number of objects pertaining to a subtree or logical subtree. Any node (object) is considered a parent to any contained objects descending therefrom, as children or child objects. Similarly, partitions (subtrees) may be parent partitions to child partitions farther removed from some root. A partition may be identified in one simple scheme by the name of the node or object entry that forms the root of the subtree representing the partition.
In a distributed directory, various partitions may be stored at numerous locations throughout a network. Nevertheless, a particular server may have a unique set of partitions, and therefore a unique set of objects. Replicas may be able to be read-only, or read/write. The operation of directory services is understood in the art.
Unfortunately, the great knowledge stored in a directory services system has not heretofore been available for ready use by a system manager for purposes of distributing software. Nevertheless, the very issues that a system manager must deal with in communication, authorization, distribution, feedback, and the like could conceivably be embodied in objects or attributes of objects within a directory services system. An apparatus and method are needed to take advantage of the information available and easily managed in a network directory services system. This information may relieve the heavy physical and logistical burden on systems managers who are trying to manage and execute the distribution of software.